home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group01b.txt / 000078_icon-group-sender_Tue Jul 3 13:37:30 2001.msg < prev    next >
Internet Message Format  |  2002-01-03  |  1KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id f63KY0s05063
  4.     for icon-group-addresses; Tue, 3 Jul 2001 13:34:00 -0700 (MST)
  5. Message-Id: <200107032034.f63KY0s05063@baskerville.CS.Arizona.EDU>
  6. From: Art Eschenlauer <art.eschenlauer@sufsys.com>
  7. To: "'icon-group@CS.Arizona.EDU'" <icon-group@cs.arizona.edu>
  8. Subject: Software testing for Icon?
  9. Date: Mon, 25 Jun 2001 11:33:50 -0500
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11. Status: RO
  12. Content-Length: 718
  13.  
  14. One concern that I expect people to raise with respect to using Icon in the
  15. "mainstream" is, "Icon cannot be trusted because it does not typecheck
  16. arguments at compile time.  How can you protect against programmer errors in
  17. the arguments passed during infrequently-executed invocations?"  I don't
  18. think that the response (however true) that C++ has compile-time
  19. type-checking and yet still is notorious for null pointer errors, etc, will
  20. convince anybody.
  21.  
  22. This raises two questions in my mind regarding Icon:
  23.  
  24. 1. Should one adopt a "defensive programming style", always checking the
  25. arguments passed to each routine?
  26.  
  27. 2. What work has been done on developing rigorous software-testing
  28. methodology for Icon programs?
  29.